home *** CD-ROM | disk | FTP | other *** search
/ Megarom / Megarom Macintosh CD Software (Quantum Leap)(1992).iso / TEXT / Downloading text < prev    next >
Text File  |  1991-10-24  |  6KB  |  107 lines
  1.  Data transfer can be done in a number of ways in on the BBS.  New error
  2.   checking protocols are being added on a regular basis, and the following
  3.   is a summary of many of those available.
  4.  
  5.  
  6.   XMODEM FILE TRANSFER - The BBS supports two variations of the XMODEM
  7.   protocol,originally developed by Ward Christensen, called XMODEM and
  8.   XMODEM/CRC respectively.  XMODEM offers the advantage of error checking
  9.   on a block by block basis to assure that the data sent contains no
  10.   errors.  It does this by adding a checksum byte to the end of each 128
  11.   byte block of data; the receiver calculates its own checksum and
  12.   compares it to the one received.  If an error is detected in the
  13.   transmission, XMODEM will request that WILDCAT! retransmit the block of
  14.   data.  In addition to the above checksum comparison, XMODEM/CRC adds
  15.   another level of error detection using a complex CYCLICAL REDUNDANCY
  16.   CHECK algorithm.
  17.  
  18.   XMODEM and XMODEM/CRC are slow transfer protocols when compared to many
  19.   others available.  They should only be used when your software supports
  20.   no other protocol.  XMODEM/CRC is preferrable to XMODEM due to its
  21.   greatly improved error checking.
  22.  
  23.   1K-XMODEM - This protocol performs exactly like regular XMODEM/CRC, but
  24.   increases the block size to 1024 bytes, hence the name 1K.  It is
  25.   slightly faster (on fairly clean phone lines) than regular XMODEM due to
  26.   a smaller number of blocks being sent, and therefore fewer block checks
  27.   being made.
  28.  
  29.   YMODEM - YMODEM is a protocol devised by Chuck Forsberg of Omen
  30.   Technology which adds a number of enhancements to protocol based
  31.   transfer. Block sizes are variable at 128/1024, but 1K is the usual
  32.   size. Error checking makes use of CRC-16, accurate to 99.99%.  By
  33.   definition, all YMODEM transfers are capable of sending multiple files
  34.   at one request, with the file size and date included in the "header
  35.   block" sent prior to each file.  YMODEM supports multiple file transfer
  36.   (both down AND up) of up to 99 files with WILDCAT!.
  37.  
  38.         CAUTION: A number of communication programs incorrectly use
  39.         the term YMODEM but actually send using 1K-XMODEM.  This
  40.         practice is not proper and will result in a failure when
  41.         used with a true YMODEM transfer as used by WILDCAT!.
  42.  
  43.   Use of YMODEM, if supported by a caller's software, is recommended over
  44.   XMODEM and 1K-XMODEM for speed, reliability, and features.
  45.  
  46.   YMODEM/G - This variation of YMODEM is available only to callers making
  47.   a "reliable" connection using a modem supporting MNP (Microcom
  48.   Networking Protocol) or the U.S. Robotics ARQ hardware error checking.
  49.   If a MNP connection is detected, WILDCAT! will add this protocol choice
  50.   (as well as 1K-XMODEM/G - see below) to the available options.
  51.  
  52.   MNP is a hardware based system in which the modems perform the actual
  53.   error checking and correction, if needed.  The software such as WILDCAT!
  54.   and Qmodem simply send the information blindly from one system to the
  55.   other using the protocol for block sorting information only.  For this
  56.   reason, these two protocol choices ONLY appear if a MNP connection is
  57.   detected at logon.
  58.  
  59.   YMODEM/G is among the fastest protocols with the exception of the newer
  60.   versions of ZMODEM discussed below.  If you have a modem that supports
  61.   MNP or ARQ, YMODEM/G should be your usual choice on the BBS. Connections
  62.   using two U.S. Robotics HST modems, with ports locked at 19200 or 38400
  63.   at both ends, results in throughput in excess of 1725 characters per
  64.   second (equivalent of over 14,000 bps)!  YMODEM/G also supports multiple
  65.   file transfer (both down AND up) of up to 99 files at on time.
  66.  
  67.   1K-XMODEM/G - This version of 1K-XMODEM makes use of MNP hardware error
  68.   correction to do away with the block-by-block checking in the normal
  69.   version.  The result is a very fast single file transfer protocol for
  70.   use if YMODEM/G is not readily available.
  71.  
  72.   ZMODEM - This is another protocol developed by Chuck Forsberg.  It is a
  73.   "streaming protocol", one which sends variable sized blocks of data with
  74.   CRC-32 error checking for an accuracy of 99.9999%, but does not wait for
  75.   an acknowledgment from the receiving computer.  The sending system
  76.   assumes data received is OK unless a repeat request is sent for a
  77.   specific block.  This streaming activity tends to make ZMODEM one of the
  78.   fastest protocols available (but very slightly slower than Ymodem/G or
  79.   1K-Xmodem/G).  ZMODEM also supports multiple file transfer capability,
  80.   and should be considered in situations where MNP is not available, or
  81.   another batch transfer protocol cannot be used.  Zmodem also has the
  82.   unique capability to resume file transfers that have been aborted for
  83.   some reason and thus only partially completed.  This is called crash
  84.   recovery.
  85.  
  86.   KERMIT - This protocol's main claim is not speed, but rather its ability
  87.   to interact with many types of computers from mainframes to micros.  It
  88.   can cope with systems limited to seven-bit characters even when the data
  89.   to be transmitted is in eight-bit form.  All characters to be sent are
  90.   translated into standard printable characters and reconstructed on the
  91.   receiving end.
  92.  
  93.   While not terribly efficient, it is sometimes an absolute necessity for
  94.   data transfer involving different types of systems and terminal types.
  95.   It is not recommended for PC to PC transfers.
  96.  
  97.   ASCII DATA CAPTURE - ASCII transfer is simply the sending of information
  98.   as characters, and is limited to 7 bit information.  The transfer of
  99.   files in ASCII mode can be done if your system is capable of any type of
  100.   data capture.  ASCII transfer is limited, and some sort of error
  101.   checking protocol is required if you intend to transfer files with
  102.   extensions of EXE, OBJ, COM, ARC or ZIP, as well as tokenized BASIC
  103.   programs and files containing the IBM PC special ASCII characters (ones
  104.   with ASCII values above 128).  These files cannot be transferred in
  105.   ASCII mode since ASCII transfer is only 7 bit and these types of files
  106.   require the full 8 bit transfer of the data, with no translation of the
  107.   contents of the file.